home *** CD-ROM | disk | FTP | other *** search
/ Internet Tools (InfoMagic) / Internet Tools.iso / dos_win / winsnmp / agent / mcsa_v08.txt < prev    next >
Text File  |  1994-10-31  |  65KB  |  1,883 lines
  1.                    Open Agent Architecture (OAA)
  2.                                   
  3.                 Multiple Component SNMP Agent (MCSA)
  4.                                   
  5.                           SNMP/MCSA/Agent
  6.                                   
  7.                               (Draft)
  8.                                   
  9.                                 by 
  10.                                   
  11.                          Bill White, et al
  12.                                   
  13.                                   
  14.                             Version 0.8
  15.                                   
  16.                               10/30/94
  17.                                   
  18.                                   
  19.  
  20.  
  21. 1.0 Multiple Component SNMP Agent (MCSA) Design Objective
  22.  
  23.      The central design objective of the MCSA agent is to allow
  24. multiple SNMP agent components from different vendors to interoperate,
  25. collectively realizing a system's SNMP agent.
  26.  
  27.      The MCSA design defines communication among SNMP agent components
  28. in system independent, message based component dialogue protocols that
  29. embody all intercomponent agent operations so they can be defined by
  30. mandatory RFCs. The design seeks to limit system dependent definitions
  31. to the specification of the method of intercomponent message exchange,
  32. mapping a primitive, generic MCSA API abstraction to each system
  33. platform's specific API by recommended RFCs.
  34.  
  35.  
  36. 1.1 Multiple Component SNMP Agent (MCSA) Reference Model  
  37.  
  38.      A system has one SNMP Agent. This agent is divided into
  39. components: an SNMP/MCSA/Agent/Master ("Agent/Master") and none or more
  40. SNMP/MCSA/Agent/SubAgentComponents ("Agent/SubAgentComponent"). Given an
  41. identical MIB state and SNMP packet, all MCSA agents should respond
  42. identically and correctly, whatever each MCSA Agent's underlying
  43. component configuration, and be externally indistinguishable from a
  44. monolithic agent.
  45.  
  46.      All intercomponent operations, either between Agent/Master and
  47. Agent/SubAgentComponent or among Agent/SubAgentComponents, are by
  48. exchange of MCSA Component Messages whose processing is defined by
  49. system independent, MCSA Component Dialogue Protocols. Intra-agent
  50. communication among an MCSA/Agent's Master and SubAgentComponents is a
  51. form of inter-process communication using messages whose medium of
  52. exchange is a function of the agent's host's system and communication
  53. configuration.
  54.  
  55.  
  56. |===============================================|
  57. |         MCSA Generic API Abstraction          |
  58. |          for MCSA Message Exchange            | (mandatory)
  59. |===============================================|
  60.         ^  |                           ^  |    
  61.         |  |                           |  |
  62.         |  | (MCSA Component Dialogue  |  |
  63.         |  |       Protocols)          |  |
  64.         |  |                           |  |
  65.         |  |       (mandatory)         |  |
  66.         |  v                           |  v     
  67.      ==============               ==============
  68.      | system-API |                | system-API |  (recommended)         
  69. |=======================|    |=======================| 
  70. |   SNMP/Agent/Master   |    | SNMP/Agent/Component-n|(vendor specific) 
  71. |=======================|    |=======================|
  72.                                   
  73.  
  74. Figure 1 - Multiple Component SNMP Agent Communications 
  75.  
  76.  
  77. 1.2 MCSA Agent/Master
  78.  
  79.      The Agent/Master is a system's end point for all incoming SNMP 
  80. packets; the overseer all SNMP packet processing; the sender of all SNMP 
  81. responses and traps. And, as such, is responsible for the agent's
  82. compliance with all SNMP protocols. An MCSA agent has one Agent/Master.  
  83.  
  84.      The Agent/Master services a known, Agent/Master message queue,
  85. providing MCSA agent wide services to other Agent/SubAgentComponents
  86. (i.e. queue management, message forwarding, system up time, resource
  87. enqueue, component registration, event subscription, etc) as defined in
  88. the Agent/Master's MCSA Component Dialogue Protocol For <dialogue_type>
  89. or participating in other Component Message exchanges with
  90. Agent/SubAgentComponents defined by the Agent/SubAgentComponent's MCSA
  91. Component Dialogue Protocol. Whenever appropriate, the Agent/Master
  92. bears the burden of processing and context retention rather than the
  93. Agent/SubAgentComponents.
  94.  
  95.  
  96. 1.3 MCSA Agent/SubAgentComponents
  97.  
  98.      Agent/SubAgentComponents provide or obtain services through the
  99. exchange of Component Messages with the Agent/Master or other
  100. Agent/SubAgentComponents as defined in the relevant MCSA Component
  101. Dialogue Protocols (i.e. Agent/SubAgentComponents that send and receive
  102. packets over a particular transport; Agent/SubAgentComponents that
  103. support ranges of OIDs). An MCSA agent may have any number of
  104. Agent/SubAgentComponents.
  105.  
  106.  
  107. 1.4 MCSA Message Exchange
  108.  
  109.      Each system platform type defines a system dependent mapping of
  110. the MCSA Generic Message Exchange API abstraction to its 
  111. <system_specific_api> in a recommended RFC - "MCSA Message Exchange API
  112. For  <system_specific>", including the system dependent definition of a
  113. component, a message queue and the method of message exchange
  114. realization. The MCSA Agent's Agent/Master and Agent/SubAgentComponents
  115. declare MCSA Message Queues and exchange MCSA Component Messages via
  116. their system's implementation of the MCSA Message Exchange. If a system
  117. has multiple processors, the MCSA Message Exchange must be implemented
  118. on all processors having MCSA message queues.
  119.  
  120.  
  121. 1.5 MCSA Hierarchy
  122.  
  123.      Agent/SubAgentComponents and the Agent/Master are the realization
  124. of the MCSA Component Dialogue Protocols they support. The MCSA
  125. Component Dialogue Protocols are made up of their Component Message
  126. definitions. Component Messages are made up of Component Message Fields
  127. and methods of implementation. Component Message Fields are made up of
  128. Field Elements and methods of implementation.
  129.  
  130. MCSA Agent
  131.  |
  132.  |
  133.  |--> Agent/Master (message queue)
  134.  |
  135.  |--> Agent/SubAgentComponent-1 (message queue)
  136.  |
  137.  |--> Agent/SubAgentComponent-n (message queue)
  138.        |
  139.        |
  140.        |--> Component Dialogue Protocol-1
  141.        |
  142.        |--> Component Dialogue Protocol-n
  143.              |
  144.              |
  145.              |--> Component Message-1
  146.              |
  147.              |--> Component Message-n
  148.                    |
  149.                    |
  150.                    |--> Message Field-1
  151.                    |
  152.                    |--> Message Field-n
  153.                          |
  154.                          |
  155.                          |--> Field Element-1
  156.                          |
  157.                          |--> Field Element-2
  158.                          |
  159.                          |--> Field Element-3
  160.             
  161.  
  162.  
  163. 2.0 MCSA Component Dialogue Protocols Defined:
  164.  
  165.  
  166. 2.1 MCSA Component Dialogue Protocol For System Time:
  167.  
  168.      This Component Dialogue Protocol defines the message exchange
  169. between the Agent/Master and Agent/SubAgentComponents for obtaining the
  170. System Up Time from the Agent/Master; obtaining system time; time
  171. delayed message forwarding; time tick message requests.
  172.  
  173.  
  174. 2.2 MCSA Component Dialogue Protocol For OID Servers:
  175.  
  176.      This Component Dialogue Protocol defines the message exchange
  177. between the Agent/Master and Agent/SubAgentComponents acting as OID
  178. servers that support resolution of one or more OID instances. The
  179. Agent/Master registers all Agent/SubAgentComponents OIDs servers,
  180. including arbitration for support conflicts and multiple component table
  181. support such as dynamic assignment of table indices. The Agent/Master
  182. exchanges Component Messages with Agent/SubAgentComponent/OIDServers to
  183. process an SNMP packet. 
  184.  
  185.  
  186. 2.3 MCSA Component Dialogue Protocol For Message Queue Services
  187.  
  188.      This Component Dialogue Protocol defines the message exchange
  189. between the Agent/Master and the Agent/SubAgentComponent/MsgQServer for
  190. registering and locating message queues; sending messages to a message
  191. queue; registering message types.  
  192.  
  193.  
  194. 2.4 MCSA Component Dialogue Protocol For Master Message Servers
  195.  
  196.      This Component Dialogue Protocol defines the message exchange
  197. between the Agent/Master and Agent/Master/MsgServer that supports the
  198. registration of components that process Agent/Master Component Messages
  199. on behalf of the Agent/Master, extending the Agent/Master.
  200.  
  201.  
  202. 2.5 MCSA Component Dialogue Protocol For OID Query [and Set?]
  203.  
  204.      This Component Dialogue Protocol defines the message exchange to
  205. allow any Agent/SubAgentComponent to query either another intrasystem
  206. OID Server or a remote SNMP agent for OID values with either a get or
  207. getnext request. 
  208.    
  209.  
  210. 2.6 MCSA Component Dialogue Protocol For Traps
  211.  
  212.      This Component Dialogue Protocol defines the message exchange to
  213. allow any Agent/SubAgentComponent to send an SNMP trap through the
  214. Agent/Master.
  215.  
  216.  
  217. 2.7 MCSA Component Dialogue Protocol For Packet Header
  218.  
  219.      This Component Dialogue Protocol defines the message exchange
  220. between the Agent/Master and a Agent/SubAgentComponent/MsgQServer for
  221. obtaining SNMP packet header information.  
  222.  
  223.  
  224. 2.8 MCSA Component Dialogue Protocol For Transport Servers:
  225.  
  226.      This Component Dialogue Protocol defines the message exchange
  227. between the Agent/Master and Agent/SubAgentComponent/Transport that send
  228. and receive SNMP packets on behalf of the Agent/Master. [TBD]
  229.  
  230.  
  231. 2.9 MCSA Component Dialogue Protocol For Resource Naming and Control
  232.  
  233.      This Component Dialogue Protocol defines the message exchange
  234. between the Agent/Master and Agent/SubAgentComponents/Resource that
  235. supports the naming of and access control to shared resources. [TBD]
  236.  
  237.  
  238. 2.10 MCSA Component Dialogue Protocol For Event Subscription
  239.  
  240.      This Component Dialogue Protocol defines the message exchange
  241. between the Agent/Master and Agent/SubAgentComponents/Event that
  242. supports the registration event publishers and subscribers. [TBD]
  243.  
  244.  
  245.  
  246. 3.0 SNMP/MCSA/Agent API
  247.  
  248.      The MCSA API is a handful of function calls needed to use and
  249. manage the MCSA Message Exchange. All other intra-agent activity is by
  250. message. 
  251.  
  252.      The MCSA-API is defined at two levels of abstraction: 
  253.  
  254.      Generic: a system independent description of MCSA Component Message
  255. Exchange objects and services, the generic MCSA Message Exchange API
  256. Abstraction.
  257.  
  258.      System Specific: a  mapping of the generic MCSA Message Exchange
  259. API Abstraction to a platform specific, system dependent specification
  260. for implementation, producing the behavior defined in the MCSA Message
  261. Exchange API Abstraction. 
  262.  
  263.      Although 'C' and 'C++' language syntax are used to define the MCSA
  264. Generic Message Exchange API standard and may often be the method for
  265. implementation of a systems's API, only the resulting operational
  266. effects, as defined by the MCSA Generic Message Exchange API, are
  267. mandatory for every MCSA system platform.
  268.  
  269.  
  270. 3.1 Generic MCSA Message Exchange API Abstraction 
  271.  
  272.      Overall, the MCSA Message Exchange converts an MCSA System
  273. Specific Message Exchange API call into MCSA Message Exchange
  274. operations: creating and destroying message queues; and, enqueuing and
  275. dequeueing Component Messages. The MCSA Message Exchange posits that
  276. byte arrays called messages may be queued to a message queue whose
  277. server will then process the messages in FIFO order.
  278.  
  279.      Because the MCSA Message Exchange access is through a system
  280. specific API, the MCSA Message Exchange services are strictly limited to
  281. those message exchange functions that can not otherwise be supported by
  282. the message based MCSA Component Dialogue Protocols (i.e. the MCSA
  283. Component Dialogue Protocol For Message Queue Services).  
  284.  
  285.  
  286. 3.1.1 Creating and Registering Agent/SubAgentComponent Message Queues
  287.  
  288.      Using the MCSA Message Exchange, an Agent/SubAgentComponent
  289. creates a message queue and obtains a unique QID, a message queue
  290. handle, from the MCSA Message Exchange by issuing a MsgQCreate API call.
  291. The MCSA Message Exchange reports to the Agent/Master via
  292. <mt_MsgQServices><QueueCreate> Component Message that a message queue is
  293. being created; in turn, the Agent/Master registers the message queue
  294. through an exchange of messages with the Agent/SubAgentComponent
  295. registering the message queue, according to the MCSA Component Dialogue
  296. Protocol For Message Queue Services. The Agent/SubAgentComponent may
  297. register multiple, system unique, text queue names for a message queue.
  298. When a message queue is created, only the Agent/Master may send it
  299. messages until the message queue is registered with the Agent/Master. By
  300. definition, an Agent/SubAgentComponent instance supports one message
  301. queue. 
  302.  
  303.      It is assumed that the Agent/Master and the implementation of the 
  304. MCSA Message Exchange come into existence at the same time and that the
  305. Agent/Master message queue is registered with the MCSA Message Exchange,
  306. a priori, with the queue name "Agent/Master" and a public QID equal to
  307. 1. In addition, all Component Dialogue Protocol For Message Queue
  308. Services message types are registered a priori. All other message queues
  309. must register with the Agent/Master before use.
  310.  
  311.  
  312. 3.1.2 Sending Component Messages 
  313.  
  314.      An Agent/SubAgentComponent sends a Component Message to any
  315. message queue, including its own message queue or the Agent/Master's
  316. message queue, by issuing a MsgSend API call. 
  317.  
  318.  
  319. 3.1.3 Locating Message Queues
  320.  
  321.      The MCSA Message Exchange locates a message queue by QID. The
  322. Agent/Master, using the MCSA Component Dialogue Protocol For Message
  323. Queue Services, supports message queue lookup by first/next message
  324. queue or by MsgQueueTextName.
  325.  
  326.  
  327. 3.1.4 Destroying Message Queues
  328.  
  329.      The Agent/Master will continue to forward encapsilated Component
  330. Messages to a registered message queue until the Agent/SubAgentComponent
  331. issues a MsgQDestroy call to the MCSA Message Exchange API causing the
  332. MCSA Message Exchange to send to the Agent/Master an
  333. <mt_MsgQServices><MessageQueueDestroy> Component Message for that
  334. message queue according to the MCSA Component Message Dialogue Protocol
  335. For Message Queue Services.
  336.  
  337.  
  338. 3.1.5 Servicing a Message Queue
  339.  
  340.      The Agent/Master and Agent/SubAgentComponents are message queue
  341. servers that process the Component Messages queued to their message
  342. queue in FIFO order by dispatching their queue server logic after
  343. issuing a MsgGet API call. The message is processed according the MCSA
  344. Component Dialogue Protocol that defines the message. While the dispatch
  345. of queue server logic is a MCSA Message Exchange operation, the
  346. execution of the queue server logic to process the message is not.
  347.  
  348.  
  349. 3.1.6 Message Queue Profile 
  350.  
  351.      The message queue's profile is not maintained by the MCSA Message
  352. Exchange itself. Instead, every message queue server sends, upon
  353. receiving a <mt_MsgQServices><MessageTypes> message, a
  354. <mt_MsgQServices><MessageTypesRsp> message(s) listing the message types
  355. it supports according to the MCSA Component Message Dialogue Protocol
  356. For Message Queue Services. A list of the message queue's registered
  357. names can be obtained sending a <mt_MsgQServices><MessageQueueNameList>
  358. message to the Agent/Master.
  359.  
  360.  
  361. 3.1.7 Message Type Scope
  362.  
  363.      All Component Messages have a message type defined by the relevant
  364. MCSA Component Dialogue Protocol or are dynamically assigned by the
  365. Agent/Master through the MCSA Component Dialogue Protocol For Message
  366. Queue Services and are unique throughout the MCSA/Agent. Each message
  367. type is uniquely defined within the MCSA Message Exchange and applies to
  368. all message queues, allowing Component Messages from any Component
  369. Message Dialogue Protocol to be serviced by the same message queue.
  370.  
  371.  
  372. 3.1.8 Message And Response Identification
  373.  
  374.      When a message is sent by the MsgSend, a unique message id is
  375. generated by the MCSA Message Exchange for the message. This message id
  376. is placed in the <mt_MsgQServices><MsgForward> Component Message by the
  377. MCSA Message Exchange and is also returned by the MsgSend function to
  378. the caller. If the encapsilated message is later forwarded by the
  379. Agent/Master to the destination queue, the Agent/Master places the
  380. message id into the unencapsulated message before queuing it to the
  381. destination message queue.
  382.  
  383.      The message id is later used to identify any responses by the
  384. placing the message id into the message response id field of the
  385. responding message(s).  
  386.  
  387.  
  388. 3.1.9 Served Message Queues
  389.  
  390.      When a message queue is created and server logic is provided, the
  391. message queue is a served message queue. When a message is queued to a
  392. served message queue, the pfnQueueServerLogic is eventually dispatched
  393. by the MCSA Message Exchange to service the message.
  394.  
  395.  
  396. 3.1.10 Utility Message Queues
  397.  
  398.      When a message queue is created and no server logic is provided,
  399. the message queue is a utility message queue. The intended use of a
  400. utility message queues by either the Agent/Master or an
  401. Agent/SubAgentComponent is for holding messages within the component. An
  402. Agent/SubAgentComponent may have multiple utility message queues.
  403.  
  404.  
  405. 3.1.11 Authentication
  406.  
  407.      MCSA Message Exchange supports authentication of message queue
  408. controlling interface calls with the user's queue creator
  409. identification, the private QID.
  410.  
  411.  
  412.  
  413. 3.1.12 Multiple Processor Discribution
  414.  
  415.      If a system's MCSA Agent is distributed across multiple processors
  416. which make up the system, then an instance of the MCSA Message Exchange
  417. must reside on each processor supporting MCSA message queues. It is
  418. within the distributed, platform specific MCSA Message Exchange that
  419. inter-processor message exchange takes place, supporting system wide,
  420. MCSA message queue access as required by the MCSA Generic Message
  421. Exchange Abstraction. The Agent/Master supports its message queue on a
  422. processor and any Agent/SubAgentComponent instance supports one message
  423. queue on one processor. 
  424.  
  425. 3.2 MCSA Message Exchange Generic API
  426.  
  427.      Every implementation of an SNMP/MCSA/Agent provides the effect of
  428. the following functions:
  429.  
  430.  
  431. 3.2.1 MsgQCreate
  432.  
  433.      QID MsgQCreate ((* pfnQueueServerLogic) (MSG *pMsg));
  434.  
  435.      MsgQCreate creates and registers the component's message queue
  436. with the MCSA Message Exchange. The returned its private message queue
  437. id (QID) is also forwarded by the MCSA Message Exchange via a
  438. <mt_MsgQServices><QueueCreate> message, notifying the Agent/Master of
  439. the new message queue's creation. The Agent/Master then registers the
  440. QID according the MCSA Message Exchange Dialogue Protocol For Message
  441. Queue Services.  
  442.  
  443.      If the pfnQueueServerLogic is NULL, the message queue is not
  444. serviced and is a utility queue; else, pfnQueueServerLogic services all
  445. messages sent to the message queue.
  446.  
  447.      The QID returned is the private QID known only to the MsgQCreate
  448. issuer. And is used only as required by the MsgQDestroy, MsgQCheck,
  449. MsgQServe and MsgSend functions for authentication. This private QID is
  450. mapped to a public QID by the MCSA Message Exchange when using the
  451. message queue's QID (i.e. source and destination addresses in a
  452. message). Only the MCSA Message Exchange or its creator may use the
  453. private QID. The Agent/Master, as an authenticated component, may delete
  454. message queues using its private QID and the subject message queue's
  455. public QID.    
  456.  
  457.  
  458. 3.2.2 MsgQDestroy 
  459.  
  460.      MsgQDestroy (QID qidMessageQueue,
  461.                 QID qidMaster);
  462.  
  463.      MsgQDestroy destroys a message queue identified by the private
  464. qidMessageQueue. If qidMessageQueue is a served message queue, the MCSA
  465. Message Exchange sends a <mt_MsgQServices><QueueDestroy> message to the
  466. Agent/Master. The Agent/Master processes the request according to the
  467. MCSA Component Dialogue Protocol For Message Queue Services, returning
  468. all unprocessed messages in the sending message queue and unregistering
  469. the message queue. In addition, the MCSA Message Exchange performs the
  470. appropriate destroy functions for the QID within any MCSA Message
  471. Exchange maintained context. The qidMaster is NULL unless the caller is
  472. the Agent/Master, then it is the Agent/Master's private QID and the
  473. qidMessageQueue is the subject message queue's public QID. 
  474.  
  475.      The MCSA Message Exchange dispatches the pfnQueueServerLogic of a
  476. served message queue with a NULL MSG pointer, indicating the message
  477. queue has been destroyed. Once the MsgQDestroy returns to the caller,
  478. the message queue can no longer be accessed by any
  479. Agent/SubAgentComponent. Whether the MsgQDestroy returns to the caller
  480. before or after the MCSA Message Exchange dispatches the
  481. pfnQueueServerLogic of the served message queue is implementation
  482. dependent. Returns 0 if success; else, no such queue.
  483.  
  484.  
  485. 3.2.3 MsgQCheck
  486.  
  487.      MsgQCheck (QID qidMessageQueue);
  488.  
  489.      The MsgQCheck returns the number of messages in the message queue
  490. identified by qidMessageQueue. If the qidMessageQueue is not valid, the
  491. value all ones is returned.
  492.  
  493.  
  494. 3.2.4 MsgQServe
  495.  
  496.      MsgQServe (QID qidMessageQueue);
  497.  
  498.      The MsgQServe causes a served message queue's pfnQueueServerLogic
  499. to be given control, whenever the next message is available in the
  500. message queue. Each MsgQServe call services one message. Returns 0 if
  501. request accepted; else, bad qidMessageQueue. Whether the MsgQServer
  502. returns only after a message is processed or immediately is system
  503. dependent. 
  504.  
  505.      When the message queue is destroyed, the pfnQueueServerLogic is
  506. dispatched with the MSG *pointer equal to NULL if a MsgQServe request is
  507. outstanding when the message queue is destroyed. If the message queue is
  508. destroyed and then a MsgQServe is issued against the message queue, a
  509. bad qidMessageQueue indication is returned.
  510.  
  511.  
  512. 3.2.5 MsgCreate
  513.  
  514.      MSG *MsgCreate (int nMaxMessageLength);
  515.  
  516.      Creates a message with all required header fields, ready to accept
  517. additional fields. Returns MSG * pointing to the message if OK; else,
  518. NULL.
  519.  
  520.  
  521. 3.2.6 MsgDestroy
  522.  
  523.      MsgDestroy (MSG *pMsg);
  524.  
  525.      Destroys a Component Message by changing the message's signature
  526. field to another value, preventing it from being processed as a message
  527. by the MCSA Message Exchange. Returns 0 if ok; else, not a Component
  528. Message.
  529.  
  530.  
  531. 3.2.7 MsgSend
  532.  
  533.      MSGID MsgSend (MSG *pMsg, QID qidSourceQueue);
  534.  
  535.      The MsgSend sends a message, pointed to by pMsg, to the message
  536. queue named in the message's destination QID, and returns a MCSA Message
  537. Exchange MSGID for the message sent. The MCSA Message Exchange places
  538. the MSGID and the public qidSourceQueue into the message before
  539. forwarding it.
  540.  
  541.      If the destination message queue is a served queue and the sender
  542. is an Agent/SubAgentComponent, the MCSA Message Exchange's API MsgSend
  543. encapsulates the Component Message into a <mt_MsgQServices><MsgForward>
  544. Component Message that it queues to the Agent/Master's message queue to
  545. be forwarded by the Agent/Master. Only the Agent/Master may send a
  546. message to a served message queue directly.
  547.  
  548.      If the destination message queue is a utility message queue, the
  549. MCSA Message Exchange's API MsgSend enqueues the Component Message
  550. directly into the utility message queue.  
  551.  
  552.  
  553. 3.2.8 MsgGet
  554.  
  555.      MSG * MsgGet (QID qidMessageQueue);
  556.  
  557.      The MsgGet dequeues a message from a utility message queue
  558. identified by qidMessageQueue. A NULL message pointer is returned if no
  559. message is in the qidMessageQueue. If qidMessageQueue is not a utility
  560. queue, all ones is returned. 
  561.  
  562.  
  563.  
  564. 4.0 Message Parsing [Is this essential?]
  565.  
  566.      FieldCreate ();
  567.      
  568.      FieldGetNext ();
  569.  
  570.      FieldAdd ();
  571.  
  572.      FieldFind ();
  573.  
  574.       FieldDestroy ();
  575.  
  576.      ElementGet ();
  577.  
  578.      ElementSet ();
  579.      
  580.  
  581.  
  582. 5.0 MCSA Inter-Component Message
  583.  
  584.      MCSA Component Messages are arrays of contiguous bytes organized
  585. into message fields. Each message field has the following field
  586. elements, in order:
  587.  
  588.      FieldType: identifies the type of field. Every FieldType is unique
  589. within the scope of a message's definition. Required FieldTypes common
  590. to all messages have the same FieldType value in all messages as
  591. possible.
  592.  
  593.      FieldLen: gives the length of the FieldData element. If you add
  594. the FieldLen to the address of the first byte of the field's FieldData,
  595. the result points to the next message field, if any. 
  596.  
  597.      FieldData: contains 0 to n bytes of data where n is FieldLen
  598. value. A field is NULL when FieldData contains 0 bytes.
  599.  
  600.  
  601. 5.1 Message Header Fields
  602.  
  603.      Each MCSA Component Message has a set of required message header
  604. fields that determines how each message is constructed and parsed. The
  605. following fields always appear at the beginning of every message, in
  606. order.
  607.  
  608.  
  609. 5.1.1 fl_Message_Key_Signature Field
  610.  
  611.      FieldType: <fl_Message_Key_Signature> (sizeof (BYTE))
  612.      FieldLen:  2 (sizeof (BYTE))
  613.      FieldData: the characters "CM" (sizeof (BYTE * 2))
  614.  
  615.      This field is the message signature field. This is the only field
  616. in Component Messages that is always the same. Any expected message not
  617. having a correct fl_Message_Key_Signature field is in error and can not
  618. be processed as a Component Message by the MCSA Message Exchange. 
  619.  
  620.  
  621. 5.1.2 fl_Message_Key_FieldType_Len Field
  622.  
  623.      FieldType: <fl_Message_Key_FieldType_Len> (sizeof (BYTE))
  624.      FieldLen:  1 (sizeof (BYTE))
  625.      FieldData: the size of the FieldType (sizeof (BYTE))
  626.  
  627.      This field gives the length of the FieldType element for all
  628. fields that follow in this message. 
  629.  
  630.  
  631. 5.1.3 fl_Message_Key_FieldLen_Len Field
  632.  
  633.      FieldType: <fl_Message_Key_FieldLen_Len>
  634.      FieldLen:  1 (sizeof (BYTE))
  635.      FieldData: size of the FieldLen (sizeof (BYTE))
  636.  
  637.      This field gives the length of the FieldLen element for all fields
  638. that follow in this message. 
  639.  
  640.  
  641. 5.1.4 fl_Message_Type Field
  642.  
  643.      FieldType: <fl_Message_Type>
  644.      FieldLen:  variable 
  645.      FieldData: this message's type.
  646.  
  647.      The MCSA Message Exchange wide, unique message type defined by a
  648. MCSA Component Dialogue Protocol and used to map the message to its own
  649. server logic within the pfnQueueServerLogic function. 
  650.  
  651.      A message type has a message type name that is represented in text
  652. in the format <DefiningDialogueProtocolName><MessageName> as in
  653. "<mt_MsgQServices><QueueCreate>", where "<mt_MsgQServices>" is the
  654. defining MCSA Message Dialogue Protocol name, in this case the MCSA
  655. Message Exchange Dialogue Protocol For Message Queues and
  656. "<QueueCreate>" is the message name. The notation "<><QueueCreate>" 
  657. means the message's protocol is within current dialogue protocol type
  658. definition.
  659.  
  660.      Except for Component Dialogue Protocol For Message Queue Services
  661. message types, all message types must be registered before they are used
  662. as a Component Message's type.
  663.  
  664.  
  665. 5.1.5 fl_Message_Length Field
  666.  
  667.      FieldType: <fl_Message_Length>
  668.      FieldLen:  variable
  669.      FieldData: the message length
  670.  
  671.      The <fl_Message_Length> is the length of a Component Message. If
  672. you add the <fl_Message_Length> to the address of the start of message
  673. (first byte of the <fl_Message_Key_Signature> field), you would point to
  674. the first byte pass the end of the message. As fields are added and
  675. deleted, the <fl_Message_Length> value changes.
  676.  
  677.  
  678. 5.1.6 fl_Message_Id Field
  679.  
  680.      FieldType: <fl_Message_Id>
  681.      FieldLen:  variable
  682.      FieldData: message id.
  683.  
  684.      The <fl_Message_Id> is the unique message id for a message
  685. instance. The MCSA Message Exchange sets the message id value when a
  686. MsgSend is issued. 
  687.  
  688.  
  689. 5.1.7 fl_Message_Id_Rsp Field
  690.  
  691.      FieldType: <fl_Message_Id_Rsp>
  692.      FieldLen:  variable
  693.      FieldData: the response id 
  694.  
  695.      The <fl_Message_Id_Rsp> is the response id of the message, 
  696. identifying the <fl_Message_Id> of the message being responded to; NULL
  697. if this message is not a response message. 
  698.  
  699.  
  700. 5.1.8 fl_Message_Destination Field
  701.  
  702.      FieldType: <fl_Message_Destination>
  703.      FieldLen:  variable
  704.      FieldData: the destination QID of the message
  705.  
  706.      The <fl_Message_Destination> is the destination QID of the
  707. message.
  708.  
  709.  
  710. 5.1.9 fl_Message_Source Field
  711.  
  712.      FieldType: <fl_Message_Source>
  713.      FieldLen:  variable
  714.      FieldData: the source QID of the message
  715.  
  716.      The <fl_Message_Source> is the public QID of the message named by
  717. the qidSourceQueue of the MsgSend.  If the <fl_Message_Source> is zero,
  718. then the source of the message was a system entity that does not service
  719. a message queue and may not be sent a response. (i.e. an interrupt
  720. handler, allowing instrumentation to communicate with the MCSA/Agent)
  721.  
  722.  
  723. 5.2 Non Header Message Fields
  724.  
  725.      Any additional field in a Component Message is defined by the
  726. message's MCSA Message Exchange Dialogue Protocol. 
  727.  
  728.  
  729.  
  730. 6.0 MCSA Component Dialogue Protocol For Message Queue Services
  731.  
  732.      The Message Queue Services protocol, <mt_MsgQServices>, describes
  733. the message exchange by which the Agent/Master provides message queue
  734. management services for Agent/SubAgentComponents that augment the
  735. minimum queue services supported by the MCSA Message Exchange through
  736. its API. The MCSA Component Dialogue Protocol For Message Queue Services
  737. message types exist a priori and the value is indicated by the notation
  738. (n) following the message type name (i.e.
  739. <mt_MsgQServices><QueueCreate>(1) indicates message type value of 1.   
  740.  
  741.      The following message definitions include only non header field
  742. definitions. Messages may or may not have fields other than message
  743. header fields. Please note: often in message definitions, fields are
  744. repeated in the response message even though they may also be in the
  745. original message which is identified by <fl_Message_Id_Rsp> field. This
  746. repetition is designed to aid the Agent/SubAgentComponent's context
  747. retention.
  748.  
  749.      Within the context of the protocol definition, "<><QueueCreate>"
  750. is equivalent to "<mt_MsgQServices><QueueCreate>".  
  751.  
  752.  
  753. 6.1 Message Type: <mt_MsgQServices><QueueCreate>(1)
  754.  
  755.      The MCSA Message Exchange sends this message to the Agent/Master
  756. when a MsgQCreate API call is made by a system component. The message's
  757. <fl_Message_Source> contains the QID of the created message queue. The
  758. Agent/Master responds by sending a <><QueueRegisterRequest> Component
  759. Message to the QID of the just created message queue.
  760.  
  761.  
  762. 6.2 Message Type: <mt_MsgQServices><QueueRegisterRequest>(2)
  763.  
  764.      This message is sent by the Agent/Master and requests that the
  765. queue's Agent/SubAgentComponent respond by sending a
  766. <><QueueRegisterName> Component Message giving a message queue text name
  767. under which the Agent/SubAgentComponent wishes to register the message
  768. queue.
  769.  
  770.  
  771. 6.3 Message Type: <mt_MsgQServices><QueueNameRegister>(3)
  772.  
  773.      FieldType: <fl_MsgQTextName>
  774.      FieldLen:  variable
  775.      FieldData: null terminated text queue name
  776.           
  777.      This message is sent by the Agent/SubAgentComponent to the
  778. Agent/Master to register a queue text name under the message's source
  779. QID.  The message queue server must respond at least once to the
  780. <><QueueRegisterRequest> message with this message or the message
  781. queue's QID is not registered with the Agent/Master. A message queue may
  782. register with no text name by responding with a NULL <fl_MsgQTextName>.
  783. This message may be sent again and again to register additional message
  784. queue text names for the source QID message queue. 
  785.  
  786.      In the <fl_MsgQTextName> FieldData, the notation "*" returns a
  787. unique queue name selected by the Agent/Master; the notation
  788. "<some_text>*" deletes the "*"  and concatenates, to the remaining
  789. <fl_MsgQTextName> string, a variable length appendage which makes the
  790. queue name unique among all registered queue names.
  791.  
  792.  
  793. 6.4 Message Type: <mt_MsgQServices><QueueNameRegisterRsp>(4)
  794.  
  795.      FieldType: <fl_MsgQTextName>
  796.      FieldLen:  variable
  797.      FieldData: null terminated text queue name
  798.  
  799.      FieldType: <fl_MsgQTextNameRegistered>
  800.      FieldLen:  variable
  801.      FieldData: null terminated text queue name
  802.  
  803.      This message is sent by the Agent/Master to the
  804. Agent/SubAgentComponent. It returns the queue text name registered under
  805. the destination QID. 
  806.  
  807.  
  808. 6.5 Message Type: <mt_MsgQServices><QueueNameList>(5)
  809.  
  810.      FieldType: <fl_QID>
  811.      FieldLen:  4
  812.      FieldData: target message queue's QID.
  813.  
  814.      This message requests the Agent/Master respond with 
  815. <><QueueNameListRsp> message that lists the message queue text names
  816. registered under the <fl_QID>.
  817.  
  818.  
  819. 6.6 Message Type: <mtMsgQServices><QueueNameListRsp>(6)
  820.  
  821.      FieldType: <fl_QID>
  822.      FieldLen:  4
  823.      FieldData: target message queue's QID.
  824.  
  825.      FieldType: <fl_MsgQTextName>
  826.      FieldLen:  variable
  827.      FieldData: null terminated text queue name
  828.  
  829.      (repeated n times)
  830.  
  831.      This message is sent by the Agent/Master to the AgentComponent
  832. listing all message queue text names a message queue under which it is 
  833. registered. The complete list may be in one or more messages sent in
  834. reply. The end of item list is indicated by a NULL <fl_MsgQTextName> in
  835. the last response message.
  836.  
  837.  
  838. 6.7 Message Type: <mt_MsgQServices><QueueNameFind>(7)
  839.  
  840.      FieldType: <fl_MsgQName>
  841.      FieldLen:  variable
  842.      FieldData: null terminated message queue text name to find.
  843.  
  844.      FieldType: <fl_CurrentQueue>
  845.      FieldLen:  4
  846.      FieldData: current QID in list.
  847.  
  848.      This message requests the Master/Agent respond with a
  849. <><QueueNameFindRsp> message returning the QID of the message queue
  850. whose name matches the search queue name, or NULL if no registered
  851. message queue had that name. If the fl_CurrentQueue is NULL, the search
  852. begins from the beginning of the registered message queue set. If the
  853. <fl_MsgQName> is NULL or "*", the next QID in the registered set is
  854. found. Wild card notation (*,?) is supported and returns the first
  855. instance found to satisfy the search argument. 
  856.  
  857.  
  858. 6.8 Message Type: <mt_MsgQServices><QueueNameFindRsp>(8)
  859.  
  860.  
  861.      FieldType: <fl_MsgQName>
  862.      FieldLen:  variable
  863.      FieldData: null terminated message queue text name to find.
  864.  
  865.      FieldType: <fl_FoundQID>
  866.      FieldLen:  4
  867.      FieldData: QID of found message queue.
  868.  
  869.      This message is sent by the Master/Agent to the
  870. Agent/SubAgentComponent in response to a <><QueueNameFind> message. 
  871.  
  872.  
  873. 6.9 Message Type: <mt_MsgQServices><QueueDestroy>(9)
  874.  
  875.      FieldType: <fl_MsgQID>
  876.      FieldLen:  4
  877.      FieldData: target message queue's QID.
  878.  
  879.      This message is sent by the MCSA Message Exchange, in response to
  880. a MsgQDestroy API call, to the Agent/Master to delete the message queue
  881. from the Agent/Master's set of registered message queues. Any Component
  882. Messages remaining in the message queue are returned to the message
  883. source by the Agent/Master, then all contexts within the Agent/Master
  884. for this QID are terminated. 
  885.  
  886.  
  887. 6.10 Message Type: <mt_MsgQServices><MessageReturn>(10)
  888.  
  889.      FieldType: <fl_MsgReturnReason> 
  890.      FieldLen:  1 
  891.      FieldData: return reason code (1 = message queue does not exist
  892.                                2 = message queue destroyed
  893.                                3 = msg type not supported)
  894.      
  895.      FieldType: <fl_MsgReturned>
  896.      FieldLen:  variable
  897.      FieldData: encapsilated message
  898.  
  899.      This message is sent to the message sender if the message can not
  900. be processed.
  901.  
  902.  
  903. 6.11 Message Type: <mt_MsgQServices><MessageForward>(11)
  904.  
  905.      FieldType: <fl_MsgToBeForwarded>
  906.      FieldLen:  variable
  907.      FieldData: encapsilated message
  908.  
  909.      This message is sent by the MCSA Message Exchange to the
  910. Agent/Master in response to a MsgSend API call by the
  911. Agent/SubAgentComponent. The Agent/Master checks the destination QID of
  912. the encapsilated message. If the QID is a registered message queue, the
  913. encapsilated message is forwarded to the destination QID message queue.
  914. If the destination QID is the Agent/Master itself, the message is
  915. processed by the Agent/Master. If the encapsilated message is not
  916. supported by the message queue, that is it contains a message type can
  917. not or should not be queued to the destination QID message queue, the
  918. encapsilated message is returned to the source QID message queue with a
  919. <><MessageReturn> message. 
  920.  
  921. [The following message_type_support messages are intended to support the
  922. coexistence of both protocol defined message types and Ad Hoc message
  923. types. As in many parts of this document, there should be a better
  924. solution than the one proposed; I just could not think of it.]
  925.  
  926. 6.12 Message Type: <mt_MsgQServices><SystemMessageTypesRegister>(12)
  927.  
  928.      FieldType: <fl_MsgTypeName>
  929.      FieldLen:  variable
  930.      FieldData: text name of a message type to be registered
  931.  
  932.      FieldType: <fl_MsgTypeType>
  933.      FieldLen:  variable
  934.      FieldData: message type to be registered
  935.  
  936.      This message is sent by an Agent/SubAgentComponent to the
  937. Agent/Master to dynamically obtain message types, including those
  938. defined in mandatory RFCs. The registration message is compared against
  939. a registered message type list maintained by the Agent/Master, each list
  940. item consisting of a <fl_MsgTypeName> and <fl_MsgTypeType>. 
  941.  
  942.      If neither the message's <fl_MsgTypeName> nor <fl_MsgTypeType> are
  943. in any Agent/Master's message type list entries, a list entry is
  944. created, registering the message type. If both the message's
  945. <fl_MsgTypeName> and <fl_MsgTypeType> are in the same list entry, the
  946. response indicates the message type is "already registered". 
  947.  
  948.      If the message's <fl_MsgTypeName> is not in the message type list
  949. and the message's <fl_MsgTypeType> is zero, the <fl_MsgTypeName> and a
  950. <fl_MsgTypeType>, dynamically assigned by Agent/Master, are registered,
  951. returning the <fl_MsgTypeType> and a response status of "ok". If the
  952. message's <fl_MsgTypeName> is in the message type list and the message's
  953. <fl_MsgTypeType> is zero, the <fl_MsgTypeType> is returned with a status
  954. of "already registered".
  955.  
  956.      Message types defined in mandatory RFCs are always registered with
  957. their RFC defined <fl_MsgTypeName>; Ad Hoc message types of Ad Hoc
  958. protocols, not defined in mandatory RFCs, are always proposed
  959. arbitrarily. The first character of an RFC defined name is "<" and the
  960. last character is ">"; Ad Hoc message type names may not have these
  961. first and last characters. Ad Hoc message type names, hopefully, migrate
  962. to RFC defined name space with the prefix "<" and suffix ">", so that
  963. one, Ad Hoc name, predicts the other, RFC defined later. 
  964.  
  965.      <mt_MsgQServices> message types are registered a priori at the
  966. startup of the MCSA Message Exchange. 
  967.      
  968.  
  969. 6.13 Message Type: <mt_MsgQServices><MessageTypeRegistrationRsp>(13)
  970.  
  971.      FieldType: <fl_Status>
  972.      FieldLen:  n bytes 
  973.      FieldData: return status 0 = ok;
  974.                                1 = already registered
  975.                           2 = message type in use
  976.                                3 = message name in use
  977.                                4 = syntax error
  978.  
  979.      FieldType: <fl_MsgTypeName>
  980.      FieldLen:  variable
  981.      FieldData: text name of a message type to be registered
  982.  
  983.      FieldType: <fl_MsgTypeType>
  984.      FieldLen:  variable
  985.      FieldData: message type dynamically assigned
  986.  
  987.      This message is sent by the Agent/Master to
  988. Agent/SubAgentComponent in response to a
  989. <><SystemMessageTypeRegistration> message. The status "syntax error"
  990. means the <><SystemMessageTypeRegistration> message fields were
  991. incorrect.   
  992.  
  993.  
  994. 6.14 Message Type: <mt_MsgQServices><MessageTypeFindName>(14)
  995.  
  996.      FieldType: <fl_MsgTypeType>
  997.      FieldLen:  variable
  998.      FieldData: message type
  999.  
  1000.      Message sent by Agent/SubAgentComponent to Agent/Master to locate
  1001. a message type by name. 
  1002.  
  1003.  
  1004. 6.15 Message Type: <mt_MsgQServices><MessageTypeFindNameRsp>(15)
  1005.  
  1006.      FieldType: <fl_MsgTypeType>
  1007.      FieldLen:  variable
  1008.      FieldData: message type
  1009.  
  1010.      FieldType: <fl_MsgTypeName>
  1011.      FieldLen:  variable
  1012.      FieldData: text name of a message type to be registered
  1013.  
  1014.      If the FieldData is NULL, the name was not found in the
  1015. Agent/Master's message type list.
  1016.  
  1017.  
  1018. 6.16 Message Type: <mt_MsgQServices><MessageTypeFindType>(16)
  1019.  
  1020.      FieldType: <fl_MsgTypeName>
  1021.      FieldLen:  variable
  1022.      FieldData: text name of a message type to be registered
  1023.  
  1024.      Message sent by Agent/SubAgentComponent to Agent/Master to locate
  1025. a message name by type. 
  1026.  
  1027.  
  1028.  
  1029. 6.17 Message Type: <mt_MsgQServices><MessageTypeFindTypeRsp>(17)
  1030.  
  1031.      FieldType: <fl_MsgTypeName>
  1032.      FieldLen:  variable
  1033.      FieldData: text name of a message type to be registered
  1034.  
  1035.      FieldType: <fl_MsgTypeType>
  1036.      FieldLen:  variable
  1037.      FieldData: message type
  1038.  
  1039.  
  1040. 6.18 Message Type: <mt_MsgQServices><QueueMessageType>(18)
  1041.  
  1042.      This message is sent to any message queue server to obtain the
  1043. message types this message queue services.
  1044.  
  1045.  
  1046. 6.19 Message Type: <mt_MsgQServices><QueueMessageTypesRsp>(19)
  1047.  
  1048.      FieldType: <fl_MsgType>
  1049.      FieldLen:  variable
  1050.      FieldData: a message type supported
  1051.  
  1052.      (repeated n times)
  1053.  
  1054.      This message is sent in response to a <><QueueMessageTypes>
  1055. message by the message queue server. The complete list may be in one or
  1056. more messages sent in reply. The end of item list is indicated by a null
  1057. message type in the last response message. 
  1058.  
  1059.  
  1060. 6.20 Message Type: <mt_MsgQServices><QueueMessageTypesChange>(20)
  1061.  
  1062.      This message is sent by an Agent/SubAgentComponent to the
  1063. Agent/Master to indicate that message registered types are now supported
  1064. or no longer supported by the Agent/SubAgentComponent's message queue.
  1065. The Agent/Master reacts to this message by sending a
  1066. <><QueueMessageTypes> message to the Agent/SubAgentComponent queue
  1067. server to obtain the message types this message queue supports.
  1068.  
  1069.  
  1070. 6.21 Message Type: <mt_MsgQServices><PublicQIDGet>(21)
  1071.  
  1072.      This message is sent by an Agent/SubAgentComponent to the
  1073. Agent/Master to get the message queue's public QID.
  1074.  
  1075.  
  1076. 7.0 MCSA Message Dialogue Protocol For Time
  1077.  
  1078.      This protocol provides an Agent/SubAgentComponent with time
  1079. services.
  1080.  
  1081.  
  1082. 7.1 Message Type: <mt_SystemTime><SystemUpTime>
  1083.  
  1084.      This message is sent by a Agent/SubAgentComponent to the
  1085. Agent/Master to obtain the SystemUpTime.
  1086.  
  1087.  
  1088. 7.2 Message Type: <mt_SystemTime><SystemUpTimeRsp>
  1089.  
  1090.      FieldType: <fl_SystemUpTime>
  1091.      FieldLen: variable 
  1092.      FieldData: system up time
  1093.  
  1094.      Message sent by the Agent/Master to the Agent/SubAgentComponent or
  1095. Agent/Master in response to a <><SystemUpTime> message.
  1096.  
  1097.  
  1098. 7.3 Message Type: <mt_SystemTime><SystemTimeCurrent>
  1099.  
  1100.      This message requests the Agent/Master's current time be sent in
  1101. reply.
  1102.  
  1103.  
  1104. 7.4 Message Type: <mt_SystemTime><SystemTimeCurrentRsp>
  1105.  
  1106.      FieldType: <fl_SystemCurrentTime>
  1107.      FieldLen:  variable 
  1108.      FieldData: current system time
  1109.  
  1110.      This message is a response to a <><SystemTimeCurrent> message and
  1111. returns the current Agent/Master's system time.
  1112.  
  1113.  
  1114. 7.5 Message Type: <mt_SystemTime><ForwardAtTime>
  1115.  
  1116.      FieldType: <fl_SystemTime>
  1117.      FieldLen:  variable 
  1118.      FieldData: system up time
  1119.  
  1120.      FieldType: <fl_encapsilated_message>
  1121.      FieldLen:  variable
  1122.      FieldData: first byte of the encapsilated message
  1123.  
  1124.      This message sets a time when to forward the encapsilated message
  1125. to its destination of QID.
  1126.  
  1127.  
  1128. 7.6 Message Type: <mt_SystemTime><TickRequest>
  1129.  
  1130.      FieldType: <fl_TickInterval>
  1131.      FieldLen:  variable 
  1132.      FieldData: time interval for tick.
  1133.  
  1134.      FieldType: <fl_TickId>
  1135.      FieldLen:  variable 
  1136.      FieldData: id of tick requested.
  1137.      
  1138.      This message is sent by any queue server requesting a  
  1139. <><TickRequestRsp> message at the interval specified until the receipt
  1140. of a <><TickRequestEnd> message.
  1141.  
  1142.  
  1143. 7.7 Message Type: <mt_SystemTime><TickRequestRsp>
  1144.  
  1145.      FieldType: <fl_TickInterval>
  1146.      FieldLen:  variable 
  1147.      FieldData: time interval for tick.
  1148.  
  1149.      FieldType: <fl_TickId>
  1150.      FieldLen:  variable 
  1151.      FieldData: Id of tick request
  1152.  
  1153.      This message is sent by the Agent/Master to the tick requestor's
  1154. message queue each fl_TickInterval until the receipt of a <><TIME
  1155. tTickRequestEnd> message.
  1156.  
  1157.  
  1158. 7.8 Message Type: <mt_SystemTime><TickRequestEnd>
  1159.  
  1160.      FieldType: <fl_TickId>
  1161.      FieldLen:  variable 
  1162.      FieldData: Id of tick request
  1163.  
  1164.      This message is sent by the tick requestor to stop the
  1165. <><TickRequestRsp> messages.
  1166.  
  1167.  
  1168.  
  1169. 8.0 MCSA Message Dialogue Protocol For OID Server
  1170.  
  1171.      This protocol allows an Agent/SubAgentComponent, the
  1172. Agent/SubAgentComponent/OIDServer, to support ranges of OIDs for the
  1173. Agent/Master's processing of get, getnext, getblk and set SNMP packets. 
  1174.  
  1175.  
  1176. 8.1 Message Type: <mt_OIDServer><OIDRangeRegister>
  1177.  
  1178.      FieldType: <fl_OIDRangeFirst>
  1179.      FieldLen: variable 
  1180.      FieldData: lowest possible OID supported
  1181.  
  1182.      FieldType: <fl_OIDRangePast>
  1183.      FieldLen: variable 
  1184.      FieldData: lowest possible OID past the last supported OID.
  1185.  
  1186.      This message is sent by an Agent/SubAgentComponent/OIDServer to
  1187. the Agent/Master to register its support for a range of OIDs. The
  1188. Agent/SubAgentComponent/OIDServer may issue many <><OIDRangeRegister>
  1189. messages to try to establish a supported range and it may support many
  1190. ranges.
  1191.  
  1192.  
  1193. 8.2 Message Type: <mt_OIDServer><OIDRangeRegisterRsp>
  1194.  
  1195.      FieldType: <fl_OIDRangeId>
  1196.      FieldLen: variable 
  1197.      FieldData: First supporting OID
  1198.  
  1199.      This message is sent by an Agent/Master to the
  1200. Agent/SubAgentComponent/OIDServer to respond to the <><OIDRangeRegister>
  1201. message.  Returns the <fl_OIDRangeId> of the supported range or NULL, if
  1202. error.
  1203.  
  1204.  
  1205. 8.3 Message Type: <mt_OIDServer><OIDRangeEnd>
  1206.  
  1207.      FieldType: <fl_OIDRangeId>
  1208.      FieldLen: variable 
  1209.      FieldData: First supporting OID
  1210.  
  1211.      This message is sent by an Agent/SubAgentComponent/OIDServer to
  1212. the Agent/Master to end its support for a range of OIDs.
  1213.  
  1214.  
  1215. 8.4 Message Type: <mt_OIDServer><OIDIndex>
  1216.  
  1217.      FieldType: <fl_OID>
  1218.      FieldLen: variable 
  1219.      FieldData: requested OID needing index
  1220.  
  1221.      This message is sent by the Agent/SubAgentComponent/OIDServer to
  1222. the Agent/Master requesting the Agent/Master generate an unique index
  1223. value to replace the last element of the requested OID, a zero. (i.e.
  1224. the request OID seeks an Agent/Master arbitrated, unique index to
  1225. replace the zero in "1.5.5.5.5.0". 
  1226.  
  1227.      It is the responsibility of the Agent/SubAgentComponent/OIDServer
  1228. to know its objects and to ask for an index where needed. The
  1229. Agent/Master keeps a list of the currently assigned indices as arbitrary
  1230. values in response to Agent/SubAgentComponent requests. Indices are
  1231. obtained for shared tables prior to issuing a <><OIDRangeRegister>
  1232. message. 
  1233.  
  1234.  
  1235. 8.5 Message Type: <mt_OIDServer><OIDIndexRsp>
  1236.  
  1237.      FieldType: <fl_OIDRangeId>
  1238.      FieldLen:  variable 
  1239.      FieldData: indexed OID returned. 
  1240.  
  1241.      This message is sent by the Agent/Master to the
  1242. Agent/SubAgentComponent/OIDServer in reply to a <><OIDIndex> message,
  1243. returning the Agent/Master generated index value for the last element
  1244. the requested OID, replacing the zero. (i.e. the response returns an
  1245. Agent/Master arbitrated, uniquely indexed OID, replacing the zero in
  1246. "1.5.5.5.5.0" with the arbitrated index and returning the indexed OID,
  1247. as in "1.5.5.5.5.3" for the selected index value of "3").
  1248.  
  1249.  
  1250. 8.6 Message Type: <mt_OIDServer><PacketProcessingStart>
  1251.  
  1252.      FieldType: <fl_PacketVersion>
  1253.      FieldLen:  variable 
  1254.      FieldData: 1 = SNMPv1 and 2 = SNMPv2
  1255.  
  1256.      FieldType: <fl_PacketCurrentView>
  1257.      FieldLen:  variable 
  1258.      FieldData: the bit representation of the current view. 
  1259.  
  1260.      FieldType: <fl_PacketTemporalDomain>
  1261.      FieldLen:  variable 
  1262.      FieldData: temporal domain. 
  1263.  
  1264.      The message is sent by the Agent/Master to all OID server message
  1265. queues at the start of packet processing and conveys information which
  1266. is does not change during the processing of the current packet.
  1267.  
  1268.  
  1269. 8.7 Message Type: <mt_OIDServer><OIDGet>
  1270.  
  1271.      FieldType: <fl_OIDRequested>
  1272.      FieldLen:  variable 
  1273.      FieldData: OID
  1274.  
  1275.      (repeats n times)
  1276.  
  1277.      The message is sent by the Agent/Master to get an OID's value.
  1278.  
  1279.  
  1280. 8.8 Message Type: <mt_OIDServer><OIDGetRsp>
  1281.  
  1282.      FieldType: <fl_OIDGetStatus>
  1283.      FieldLen:  variable 
  1284.      FieldData: return status 0 = ok;
  1285.                                1 = not found
  1286.  
  1287.      FieldType: <fl_OIDGetNextIndex>
  1288.      FieldLen:  variable 
  1289.      FieldData: index to error field, if error status
  1290.  
  1291.      FieldType: <fl_OIDRequested>
  1292.      FieldLen:  variable 
  1293.      FieldData: OID
  1294.  
  1295.      FieldType: <fl_OIDGetValue>
  1296.      FieldLen:  variable 
  1297.      FieldData: OID value
  1298.  
  1299.      (repeats n times)
  1300.  
  1301.      The message sent by the Agent/SubAgentComponent/OIDServer to the
  1302. Agent/Master in response to a <><OIDGet> message.
  1303.  
  1304.  
  1305. 8.9 Message Type: <mt_OIDServer><OIDGetNext>
  1306.  
  1307.      FieldType: <fl_OIDRequested>
  1308.      FieldLen:  variable 
  1309.      FieldData: OID
  1310.  
  1311.      (repeats n times)
  1312.  
  1313.      The message is sent by the Agent/Master to get the next OID's
  1314. value.
  1315.  
  1316.  
  1317. 8.10 Message Type: <mt_OIDServer><OIDGetNextRsp>
  1318.  
  1319.      FieldType: <fl_OIDGetNextStatus>
  1320.      FieldLen:  variable 
  1321.      FieldData: return status 0 = ok;
  1322.                                1 = not found
  1323.  
  1324.      FieldType: <fl_OIDGetNextIndex>
  1325.      FieldLen:  variable 
  1326.      FieldData: index to error field, if error status
  1327.  
  1328.      FieldType: <fl_OIDGetNextOID>
  1329.      FieldLen:  variable 
  1330.      FieldData: next OID.
  1331.  
  1332.      FieldType: <fl_OIDGetNextValue>
  1333.      FieldLen:  variable 
  1334.      FieldData: value of next OID.
  1335.  
  1336.      (last two fields repeat n times)
  1337.  
  1338.  
  1339.      This message is sent in response to a <><OIDGetNext> message,
  1340. returning the next OID and its value, or error. 
  1341.  
  1342.  
  1343.      
  1344. <mt_OIDServer><OIDGet>
  1345.  
  1346.  
  1347.  
  1348.  
  1349. 8.11 Message Type: <mt_OIDServer><OIDSetGetStateRsp> 
  1350.  
  1351.      FieldType: <fl_OIDSetStatus>
  1352.      FieldLen:  variable 
  1353.      FieldData: return status 0 = ok;
  1354.                                1 = not found
  1355.                                2 = read only
  1356.  
  1357.      FieldType: <fl_OIDValue>
  1358.      FieldLen:  variable 
  1359.      FieldData: OID value
  1360.  
  1361.      (repeats n times) 
  1362.  
  1363.      This message returns the OID's current value, if found and may be
  1364. set. The Agent/Master uses the response to build an undo table
  1365. consisting of the OID, OIDValueCurrent and OIDValueNew for each var in
  1366. the set packet in case of transaction backoff. 
  1367.  
  1368.  
  1369. 8.13 Message Type: <mt_OIDServer><OIDSetPosit>
  1370.  
  1371.      FieldType: <fl_OIDRequested>
  1372.      FieldLen:  variable 
  1373.      FieldData: OID  
  1374.  
  1375.      FieldType: <fl_OIDToSet>
  1376.      FieldLen:  variable 
  1377.      FieldData: OID  
  1378.  
  1379.      FieldType: <fl_OIDValueNew>
  1380.      FieldLen:  variable 
  1381.      FieldData: OID value
  1382.  
  1383.      (<fl_OIDToSet>, <fl_OIDValueCurrent> and <fl_OIDValueNew> repeats
  1384. for n times, where n is the number of entries in the Agent/Master's
  1385. original value table to support undo )  
  1386.  
  1387.      This message is sent by the Agent/Master, for each OID in the
  1388. original OID value table, to a Agent/SubAgentComponent/OIDServer test if
  1389. the value is a proper value. The Agent/SubAgentComponent/OIDServer
  1390. should check the new value of the OID for consistency with: 1) the OID
  1391. itself; 2) all other Set new values in the message; 3) any other system
  1392. states. The Agent/SubAgentComponent/OIDServer should use the
  1393. <><mt_OIDQuery> message to query other Agent/SubAgentComponent/OIDServer
  1394. for values needed during the consistency testing.
  1395.  
  1396.  
  1397. 8.14 Message Type: <mt_OIDServer><OIDSetPositRsp> 
  1398.  
  1399.      FieldType: <fl_OIDSetStatus>
  1400.      FieldLen:  variable 
  1401.      FieldData: return status 0 = ok;
  1402.                                1 = conflict found
  1403.  
  1404.      This message is sent by the Agent/SubAgentComponent/OIDServer to
  1405. the Agent/Master after checking for value consistency. If an error is
  1406. returned by any Agent/SubAgentComponent/OIDServer, the
  1407. <><PacketProcessingEnd> message is sent to all
  1408. Agent/SubAgentComponent/OIDServers and an error is reported by the
  1409. Agent/Master to the SNMP packet sender. 
  1410.  
  1411.  
  1412. 8.16 Message Type: <mt_OIDServer><OIDSetCommit>
  1413.  
  1414.      FieldType: <fl_OIDRequested>
  1415.      FieldLen:  variable 
  1416.      FieldData: OID  
  1417.  
  1418.      FieldType: <fl_OIDValueNew>
  1419.      FieldLen:  variable 
  1420.      FieldData: OID new set value for target OID
  1421.  
  1422.      (last two fields repeat n times)
  1423.  
  1424.      This message is sent by the Agent/Master to the appropriate
  1425. Agent/SubAgentComponent/OIDServer, after all <><OIDSetPositRsp> messages
  1426. return ok, to set the OID's new value. The Agent/Master sends one
  1427. <><OIDSetCommit> message at a time and awaits a response before sending
  1428. the next.
  1429.  
  1430.  
  1431. 8.17 Message Type: <mt_OIDServer><OIDSetCommitRsp> 
  1432.  
  1433.      FieldType: <fl_OIDSetStatus>
  1434.      FieldLen:  variable 
  1435.      FieldData: return status 0 = ok;
  1436.                                1 = set failed
  1437.  
  1438.      This message is sent by the Agent/SubAgentComponent/OIDServer to
  1439. the Agent/Master to report the status of a <><OIDSetCommit> message. If
  1440. the <fl_OIDSetStatus> is ok, Agent/Master sends the <><OIDSetCommit>
  1441. message for the next set OID. If the <fl_OIDSetStatus> is failed,
  1442. Agent/Master sends a <><OIDSetUnDo> message for each OID that has
  1443. already reported an <fl_OIDSetStatus> of ok and set its new value, to
  1444. undo the set (maybe impossible) using the original value table.   
  1445.  
  1446.  
  1447. 8.18 Message Type: <mt_OIDServer><OIDSetUnDo>
  1448.  
  1449.      FieldType: <fl_OIDRequested>
  1450.      FieldLen:  variable 
  1451.      FieldData: OID  
  1452.  
  1453.      FieldType: <fl_OIDValueNew>
  1454.      FieldLen:  variable 
  1455.      FieldData: OID new set value for target OID
  1456.  
  1457.      This message is sent by the Agent/Master to the appropriate
  1458. Agent/SubAgentComponent/OIDServer, after a failed ><OIDSetCommitRsp>
  1459. message, to attempt to undo a commit. The Agent/Master sends one
  1460. <><OIDSetUnDo> message at a time and awaits a response before sending
  1461. the next.
  1462.  
  1463. 8.19 Message Type: <mt_OIDServer><OIDUnDoRsp>
  1464.  
  1465.      FieldType: <fl_OIDUnDoStatus>
  1466.      FieldLen:  variable 
  1467.      FieldData: return status 0 = ok;
  1468.                                1 = no undo possible
  1469.  
  1470.      FieldType: <fl_OIDRequested>
  1471.      FieldLen:  variable 
  1472.      FieldData: OID
  1473.  
  1474.      FieldType: <fl_OIDGetStatus>
  1475.      FieldLen:  variable 
  1476.      FieldData: return status 0 = ok;
  1477.                                1 = not found
  1478.  
  1479.  
  1480. 8.20 Message Type: <mt_OIDServer><PacketProcessingEnd>
  1481.  
  1482.      This message is sent by the Agent/Master to all registered
  1483. Agent/SubAgentComponent/OIDServer to indicate the packet context need no
  1484. longer be retained because packet processing is complete. 
  1485.  
  1486.  
  1487.  
  1488. 9.0 MCSA Component Dialogue Protocol For OID Query [and Set?]
  1489.  
  1490.      The purpose of the Component Dialogue Protocol For OID Query and
  1491. [and Set ?] is to allow any Agent/SubAgentComponent to query either an
  1492. intrasystem OID Server or a remote SNMP agent for OID values with either
  1493. a get or getnext request. [If Set were allowed and ICMP query protocol
  1494. were also supported, then an SNMP/MCSA/Agent/SubAgentComponent could be
  1495. a message based SNMP/MCSA/NetworkManagementStation.]   
  1496.  
  1497.  
  1498. 9.1 Message Type: <mt_OIDQuery><OIDIntraSystemGet>
  1499.  
  1500.      FieldType: <fl_OIDRequested>
  1501.      FieldLen:  variable 
  1502.      FieldData: OID
  1503.  
  1504.      The message is sent by the Agent/SubAgentComponent to the
  1505. Agent/Master to get an OID's value from among this agent's
  1506. Agent/SubAgentComponent/OIDServers. To limit recursion, the Agent/Master
  1507. allows only n (system dependent) messages of this type to be outstanding
  1508. from an Agent/SubAgentComponent at a time.
  1509.  
  1510.  
  1511. 9.2 Message Type: <mt_OIDServer><OIDIntraSystemGetRsp>
  1512.  
  1513.      FieldType: <fl_OIDGetStatus>
  1514.      FieldLen:  variable 
  1515.      FieldData: return status 0 = ok;
  1516.                                1 = not found
  1517.  
  1518.      FieldType: <fl_OIDGetValue>
  1519.      FieldLen:  variable 
  1520.      FieldData: OID value
  1521.  
  1522.      The message sent by the Agent/Master to the
  1523. Agent/SubAgentComponent/OIDServer in response to a <><OIDIntraSystemGet>
  1524. message. 
  1525.  
  1526.  
  1527. 9.3 Message Type: <mt_OIDQuery><OIDIntraSystemGetNext>
  1528.  
  1529.      FieldType: <fl_OIDRequested>
  1530.      FieldLen:  variable 
  1531.      FieldData: OID
  1532.  
  1533.      The message is sent by the Agent/SubAgentComponent to the
  1534. Agent/Master to get the next OID's value from among this agent's
  1535. Agent/SubAgentComponent/OIDServers. To limit recursion, the Agent/Master
  1536. allows only n (system dependent) messages of this type to be outstanding
  1537. from an Agent/SubAgentComponent at a time.
  1538.  
  1539.  
  1540. 9.4 Message Type: <mt_OIDQuery><OIDIntraSystemGetNextRsp>
  1541.  
  1542.      FieldType: <fl_OIDGetNextStatus>
  1543.      FieldLen:  variable 
  1544.      FieldData: return status 0 = ok;
  1545.                                1 = not found
  1546.  
  1547.      FieldType: <fl_OIDGetNextOID>
  1548.      FieldLen:  variable 
  1549.      FieldData: next OID.
  1550.  
  1551.      FieldType: <fl_OIDGetNextValue>
  1552.      FieldLen:  variable 
  1553.      FieldData: value of next OID.
  1554.  
  1555.      This message is sent in response to a <><OIDInterSystemGetNext>
  1556. message, returning the next OID and its value, or error. 
  1557.  
  1558.  
  1559. 9.5 Message Type: <mt_OIDQuery><OIDInterSystemGet>
  1560.  
  1561.      FieldType: <fl_IPAdr>
  1562.      FieldLen:  variable 
  1563.      FieldData: Remote agent's IP address
  1564.  
  1565.      FieldType: <fl_OIDRequested>
  1566.      FieldLen:  variable 
  1567.      FieldData: OID
  1568.  
  1569.      (last field repeated n times)
  1570.  
  1571.      The message is sent by the Agent/SubAgentComponent to the
  1572. Agent/Master to get OIDs' value from another snmp agent. To limit
  1573. recursion, the Agent/Master allows only n (system dependent) messages of
  1574. this type to be outstanding from an Agent/SubAgentComponent at a time.
  1575. [this should be handled as a value associated with the resource naming
  1576. and control server.]
  1577.  
  1578.  
  1579. 9.6 Message Type: <mt_OIDServer><OIDInterSystemGetRsp>
  1580.  
  1581.      FieldType: <fl_OIDGetStatus>
  1582.      FieldLen:  variable 
  1583.      FieldData: return status 0 = ok;
  1584.                                1 = not found
  1585.  
  1586.      FieldType: <fl_OIDGetStatusIndex>
  1587.      FieldLen:  variable 
  1588.      FieldData: if not found, error index: 1 = first
  1589.  
  1590.      FieldType: <fl_IPAdr>
  1591.      FieldLen:  variable 
  1592.      FieldData: OID
  1593.  
  1594.      FieldType: <fl_OIDGetValue>
  1595.      FieldLen:  variable 
  1596.      FieldData: OID value
  1597.  
  1598.      (last two fields repeated n times)
  1599.  
  1600.      The message sent by the Agent/Master to the
  1601. Agent/SubAgentComponent/OIDServer in response to a <><OIDInterSystemGet>
  1602. message. 
  1603.  
  1604.  
  1605. 9.7 Message Type: <mt_OIDQuery><OIDInterSystemGetNext>
  1606.  
  1607.      FieldType: <fl_IPAdr>
  1608.      FieldLen:  variable 
  1609.      FieldData: Remote agent's IP address
  1610.  
  1611.      FieldType: <fl_OIDRequested>
  1612.      FieldLen:  variable 
  1613.      FieldData: OID
  1614.  
  1615.      (last field repeated n times)
  1616.  
  1617.  
  1618.  
  1619.      The message is sent by the Agent/SubAgentComponent to the
  1620. Agent/Master to get the next OID's value from another system. To limit
  1621. recursion, the Agent/Master allows only n (system dependent) messages of
  1622. this type to be outstanding from an Agent/SubAgentComponent at a time.
  1623.  
  1624.  
  1625. 9.8 Message Type: <mt_OIDQuery><OIDInterSystemGetNextRsp>
  1626.  
  1627.      FieldType: <fl_OIDGetNextStatus>
  1628.      FieldLen:  variable 
  1629.      FieldData: return status 0 = ok;
  1630.                                1 = not found
  1631.  
  1632.      FieldType: <fl_OIDGetNextStatusIndex>
  1633.      FieldLen:  variable 
  1634.      FieldData: if not found, error index: 1 = first
  1635.  
  1636.      FieldType: <fl_OIDGetNextOID>
  1637.      FieldLen:  variable 
  1638.      FieldData: next OID.
  1639.  
  1640.      FieldType: <fl_OIDGetNextValue>
  1641.      FieldLen:  variable 
  1642.      FieldData: value of next OID.
  1643.  
  1644.      (last two fields repeated n times)
  1645.  
  1646.      This message is sent in response to a <><OIDInterSystemGetNext>
  1647. message, returning the next OID and its value, or error. 
  1648.  
  1649.  
  1650.    
  1651.  
  1652. 10.0 MCSA Component Dialogue Protocol For Traps
  1653.  
  1654.      This Component Dialogue Protocol defines the message exchange to
  1655. allow any Agent/SubAgentComponent to send a trap through the
  1656. Agent/Master.
  1657.  
  1658. 10.1 Message Type: <mt_Trap><Send>
  1659.  
  1660.      The message sent by the Agent/SubAgentComponent/OIDServer to the
  1661. Agent/Master requesting a trap be sent. 
  1662.  
  1663.      FieldType: <fl_TrapPacket>
  1664.      FieldLen:  variable
  1665.      FieldData: SNMP trap packet
  1666.  
  1667. 10.2 Message Type: <mt_Trap><SendRsp> 
  1668.  
  1669.      The message sent by the Agent/Master to
  1670. Agent/SubAgentComponent/OIDServer responding to the <><Send> message.
  1671.  
  1672.      FieldType: <fl_TrapStatus>
  1673.      FieldLen:  <variable> 
  1674.      FieldData: 0 = trap sent;
  1675.                  1 = declined (syntax error)
  1676.                  2 = declined (not allowed) 
  1677.  
  1678.       FieldType: <fl_TrapErrorOffset>
  1679.      FieldLen:  <variable> 
  1680.      FieldData: offset to error from <fl_TrapPacket>
  1681.       
  1682.      FieldType: <fl_TrapPacket>
  1683.      FieldLen:  variable
  1684.      FieldData: SNMP trap packet
  1685.  
  1686. 11.0 MCSA Component Dialogue Protocol For Packet Header
  1687.  
  1688.      This Component Dialogue Protocol defines the message exchange
  1689. between the Agent/Master and a Agent/SubAgentComponent/MsgQServer for
  1690. obtaining SNMP packet header information. of the packet currently being
  1691. processed or last one processed.  
  1692.  
  1693.  
  1694. 11.1 Message Type: <mt_PacketHeader><Get>
  1695.  
  1696.      The message sent by the Agent/SubAgentComponent/OIDServer to the
  1697. Agent/Master requesting the header of the last packet received. 
  1698.  
  1699.  
  1700. 11.2 Message Type:<mt_PacketHeader><GetRsp> 
  1701.  
  1702.      The message sent by the Agent/Master to
  1703. Agent/SubAgentComponent/OIDServer responding to the header request.
  1704.  
  1705.      FieldType: <fl_GetStatus>
  1706.      FieldLen:  2 
  1707.      FieldData: BYTE byte_1 = 0 if ok, 1 = no packet received.
  1708.                  BYTE byte_2 = 0 if processing packet; 1 = if
  1709.                                  old packet 
  1710.  
  1711.      FieldType: <fl_GetHeader>
  1712.      FieldLen:  variable
  1713.      FieldData: SNMP packet header
  1714.  
  1715.  
  1716. 12.0 MCSA Component Dialogue Protocol For Agent/Master/Servers 
  1717.  
  1718.      The Agent/Master is itself extensible by adding to the system
  1719. Agent/Master/Server components, a type of Agent/SubAgentComponent, that
  1720. processes types of messages from the Agent/Master's message queue on
  1721. behalf of the Agent/Master. An Agent/Master/Server component does this
  1722. by registering with the Agent/Master a set of message types it supports
  1723. for the Agent/Master message queue. When an Agent/Master/Server
  1724. component registers with the Agent/Master, the message types are linked
  1725. to the QID of the Agent/Master/Server. Later, the Agent/Master forwards
  1726. to the Agent/Master/Server's own message queue any Agent/Master message
  1727. queue message with the message types registered by the
  1728. Agent/Master/Server component.
  1729.  
  1730.      The primary function of Agent/Master/Server components is to allow
  1731. the Agent/Master to expand its capabilities as a correspondent in new
  1732. Component Dialogue Message Protocols without replacing the original
  1733. Agent/Master. This supports new Agent/SubAgentComponent classes that
  1734. require Agent/Master participation in the new Component Dialogue Message
  1735. Protocol whose context it maintains. The Agent/Master/Server's access to
  1736. the Agent/Master's context is by message.
  1737.  
  1738.      The combination of dynamic message type definition with extensible
  1739. Agent/Master/Server and Agent/SubAgentComponents allows for full agent
  1740. extensibility as well as migration from Ad Hoc to RFC defined protocols.
  1741.  
  1742.      The following message definitions include only those fields that
  1743. are not required in every message.
  1744.  
  1745.  
  1746. 12.1 Message Type: <mt_MasterMessageServer><RegisterType>
  1747.  
  1748.      FieldType: <fl_Message_Type>
  1749.      FieldLen:  variable 
  1750.      FieldData: a message type to be supported by the source QID.
  1751.  
  1752.      (repeated n times)
  1753.  
  1754.      This message is sent by an Agent/Master/Server to the Agent/Master
  1755. to register a message type of the Agent/Master's message queue that is
  1756. serviced by the source QID. The complete list may be in one or more
  1757. messages. The end of item list is indicated by a null message type in
  1758. the last message. The message type registration must be executed by a
  1759. single list. The sending of a subsequent list unregisters the message
  1760. types of the previous list. The sending of a null list unregisters all
  1761. registered message types for source QID without registering any new
  1762. message type.
  1763.  
  1764.  
  1765. 12.2 Message Type: <mt_MasterMessageServer><RegisterTypeRsp>
  1766.  
  1767.      FieldType: <fl_Message_Type_Rsp>
  1768.      FieldLen:  variable 
  1769.      FieldData: response (0 if the complete list is accepted; 
  1770.                            else, if the list is rejected, the first
  1771.                            message type rejected.) 
  1772.  
  1773.  
  1774. 13.0 MCSA Component Dialogue Protocol Traps
  1775.  
  1776.      The purpose of the Component Dialogue Protocol For Traps is to
  1777. allow SNMP/MCSA/Agent/SubAgentComponens to send traps.
  1778.  
  1779.  
  1780. 13.1 Message Type: <mt_Traps><TrapSend>
  1781.  
  1782.      FieldType: <fl_IPAdr>
  1783.      FieldLen:  variable 
  1784.      FieldData: Remote agent's IP address
  1785.  
  1786.      (repeated 0-n times)
  1787.  
  1788.  
  1789.      FieldType: <fl_TrapMsg>
  1790.      FieldLen:  variable
  1791.      FieldData: encapsilated message
  1792.  
  1793.  
  1794.      FieldType: <fl_IPAdr>
  1795.      FieldLen:  variable 
  1796.      FieldData: Remote agent's IP address
  1797.  
  1798.      (repeated 0-n times)
  1799.  
  1800.  
  1801.      This message is sent by an Agent/SAC to the Agent/Master to send a
  1802. trap message. One or more <fl_IPAdr> fields are present, they can appear
  1803. both before and after the <fl_TrapMsg>.
  1804.  
  1805.  
  1806.      
  1807. 13.2 Message Type: <mt_Traps><TrapSendRsp>
  1808.  
  1809.  
  1810.      FieldType: <fl_OIDGetNextStatus>
  1811.      FieldLen:  variable 
  1812.      FieldData: return status 0 = ok;
  1813.                                1 = not sent
  1814.  
  1815.  
  1816.      FieldType: <fl_IPAdr>
  1817.      FieldLen:  variable 
  1818.      FieldData: Remote agent's IP address
  1819.  
  1820.      (repeated n times)
  1821.  
  1822.  
  1823.  
  1824.  
  1825.  
  1826.  
  1827. 14.0 Contributors To This Document
  1828.  
  1829.      While Bill White is the principal author of this draft, it is a
  1830. work of many. All those below have contributed to the document. Any
  1831. errors in the document are their fault entirely.
  1832.  
  1833.      
  1834.      Anonymous
  1835.  
  1836.      Carl Auerback
  1837.  
  1838.      Larry Backman, FTP
  1839.  
  1840.      Roger Booth, Network Managers, Ltd
  1841.  
  1842.      Andy Bierman, Synoptics 
  1843.  
  1844.      Geoff Carpenter, IBM 
  1845.  
  1846.      Alexander Dupuy
  1847.  
  1848.      Truong Huy, Tandem
  1849.  
  1850.      Dave Meldrum, Sybase
  1851.  
  1852.      Bob Natale, American Compuper
  1853.  
  1854.      David Perkins, Bay Networks
  1855.  
  1856.      Sudhie Pendse
  1857.  
  1858.      Randy Presuhn, Peer Networks
  1859.  
  1860.      Mary Quinn, FTP
  1861.  
  1862.      Alex Romanov, Paul Freeman Associates
  1863.  
  1864.      Tim Salmon
  1865.  
  1866.      Cindy Schlener, DEC
  1867.  
  1868.      Reuben D. Sivan, Multiport Corp
  1869.  
  1870.      Timon Sloane
  1871.  
  1872.      Henry Teng, DEC
  1873.  
  1874.      Jim West, MQXM Corporation
  1875.  
  1876.      Bill White, Westford Systems, Inc
  1877.  
  1878.      Bert Wijen
  1879.  
  1880.      Pete Wilson, Paul Freeman Associates
  1881.  
  1882.      Carl Wohlforth, Novell
  1883.